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Task Force Team Members 


Agency Points of Contact: 
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JAXA: Masafumi Katahira 
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JAXA: Masafumi Katahira, Tatsuya Kaneko, 

Tetsuya Nakano, Masarni Mitsui 
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Purpose of the Task Force 


Interest in a cooperative activity among JAXA, ESA, 
NASA was expressed at 2009 Trilateral meeting 
“Mutual recognition of S&MA standards” 


Purposes: 

- To improve mutual understanding of each Agency’s 
Standards and technical commonalities/differences 

- To create a reference 

- To discuss future usage of those task force products 



Cross-reference of software standards 

Approach 



Reference 


• ISOI 2207-1 995 was selected because ISO 12207 is 
commonly used internationally 

- ISOI 2207-1 995 contains 29 processes 

- All Agencies’ Standards total over 550 requirements 





Work to Date 

team communicated via monthly telecon/webex sessions and email 


Each Agency mapped their Standards/requirements to 
the chosen “reference” of ISO 12207-1995 

Each Agency reviewed the mappings done by the other 
Agencies and provided questions/comments/clarification 

Each Agency worked to describe how completely the 
Agencies’ requirements met each ISO requirement 



Documents Used by Task Force 


International Core Standard : 

ISO 12207-1995, Information technology - Software life cycle processes 

ESA Documents: 

ECSS-E-40C: Space Engineering Software Standard 

ECSS-Q-40C : Space Product Assurance Software Product Assurance 

JAXA Document: 

JERG-2-600: Software Development Standard 

NASA Documents: 

NPR 71 50. 2 A: NASA Software Engineering Requirements 
NASA-STD-8739.8: Software Assurance Standard 
NASA-STD-8719. 13: Software Safety Standard 



Lessons Learned 


• Analysis Process & Result 

- Software Assurance was a good choice and is relevant to all 
3 Agencies. 

- Choosing a 'neutral' standard to use as the basis for 
comparison of each Agency's document set to was a good 
method. It provided a common reference point and put the 
3 Agencies on equal footing. 

- Comparison codes were effective for discussion and to 
quantify results. 

- The analysis has been time-consuming and labor-intensive, 
but has produced a useful product and improved 
communication and understanding. 
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Results 


No major disconnects were identified. 

Analysis of ISO-12207 Section 6.4, Verification, was done by 
all 3 Agencies 

Analysis of ISO-12207 Section 6.5, Validation, was done only 
by NASA 

- For the following two slides, the charts and data 
underlying the charts is based on NASA's preliminary 
analysis of information from the above. 

- A requirement "matches" the ISO requirement if the 
text, intent and/or information provided by the Agency is 
deemed to satisfy the ISO requirement, including by 
identical wording or equivalence. 

- A requirement is also considered matched when a 
combination of multiple Agency requirements can be 
used to satisfy one ISO requirement. 




NASA's preliminary analysis) 


Mapping t 
ISO 12207 
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I 3 Agencies match, 
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1 Agency matched 


Agency documents and 


Results 

6,5 Validation (results shown based on NASA's preliminary analysis) 


Mapping the requirements between Agency documents and 
ISO 12207-1995 Section 8.5 showed: 

- AH ISO requirements were matched by at least one Agency. 

- 39% of the ISO requirements - all 3 Agencies match, 

- 50% of ISO requirements - 2 out of 3 Agencies match, 

- 11% of ISO requirements - Only 1 Agency matched 


ONE 

AGENCY 

11 % 


NASA 





T ALL THREE 


Jill 
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Task Force Observations 


Task Force Purposes: 

- To improve mutual understanding of each Agency’s 
Standards and technical commonalities/differences 

• Observation #1: The analysis performed has been useful in 
improving awareness and understanding among the task force 
members and their Agencies. 

• Observation #2: Educational presentations by task force members 
have increased shared understanding of how the Agencies view 
and implement verification and validation activities. 

- To create a reference 

• Observation #3: The analysis performed has resulted in a matrix 
which could (once final review is completed) be used as an 
informal reference when working on joint projects. 

- To discuss future usage of those task force products 

• Observation #4: During the analysis, review and communication 
activities, each Agency has noted possible opportunities for 
improvement in their own documentation through comparison 
with the documentation of the other Agencies. 



Conclusion 

• At the level of Agency requirements, it appears to be 
infeasible to perform an analysis with sufficient detail and 
confidence to enable the potential reduction of 
"redundant" activities. 

This conclusion is based on a number of factors, including: 

— The limited insight available at the requirement level 

- The fact that similarity or commonality of requirements does not 
automatically imply overlapping or redundant tasks/activities 
(tasks are at a lower level than requirements) 

HOWEVER: 

• The matrix generated by the Task Force Team's analysis 
could be used at a project level to identify areas for further 
detailed technical discussion and information sharing. 

• Such discussions could enable mutual agreements on 
specific projects and improve our individual and joint 
efforts in the future. 



Task Force Recommendation 


Each Agency should internally review and agree to a final 
version of the mapping matrix, which can then be informally 
distributed or made available to our internal Software 
Assurance communities. 

Appropriate caveats need to accompany the matrix when distributed, 
for example: 

• For use within (Agency name) only, not for distribution 

• Reference/information document only, not policy or guidance 

• Based on specific versions of the Agency's and ISO standards, 
check that those versions are still in use 

• If any questions arise, contact the appropriate Agency Task Force 
Team POC. 

Each Agency will keep the others informed of future updates 
to the Agency documents used in this mapping effort. 



Thank You 


On behalf of the members of the Software Assurance 
Task Force members, Thank you for supporting our 
efforts. We all feel that we have come a long way 
towards understand each others requirements and 
that our Agencies can better work together. 



